1. Technical Field
The present invention relates generally to an improved data processing system. In particular, the present invention relates to a method, apparatus, and computer instructions for defining queries in terms of named data objects.
2. Description of Related Art
Object-oriented programming techniques involve the definition, creation, use, and instruction of “objects”. These objects are software entities comprising data elements or attributes and methods, which manipulate data elements. Objects also may include data related to events outside of the object to trigger or control methods within the object.
Data objects modeled in an object-oriented system typically represent data from a backend data store. In the current art, several methods exist to construct and populate data objects. One such method includes modeling data objects to represent lightweight constructs. These lightweight constructs contain data from Entity Enterprise Java Beans (EJBs). Another existing method to construct and populate data objects includes using an object model where data objects represent rows in tables in a relational database. In this particular implementation, the “class” of the data object models the shape from the database table, and instances of the data object represent individual rows from the table.
Data objects reference other data objects, and collectively compose a “data graph”. A data graph is a collection of tree-structured or graph-structured data objects. Applications typically define data sources which can be used by mediators for fetching data, constructing, populating, and linking data objects, and returning a data graph. A mediator carries out the backend specific details of retrieving and storing the data requested by the application. For example, one might have an Enterprise JavaBeans (EJB) mediator, a Java Database Connectivity (JDBC) mediator, or an Extensible Markup Language (XML) mediator, etc.
Regardless of the specific mediator service utilized, a mediator requires information concerning the “shape” of the data in order to know how to perform a query. The shape can be described as the attributes, or fields of an object, and the references, or relationships, it contains to other objects. The shape of the object is used to generate a query, whose “shape” is defined by the column values to be retrieved. For example, a JDBC mediator might be given a Structured Query Language (SQL) string, such as “Select a.street, a.city, a.state, a.zip from address as a”, in order to fetch a list of addresses from the database and construct “AddressLite” data objects, with named attributes “street”, “city”, “state”, and “zip”.
The problem with existing art is that the shape of the data is defined in two places. Using a meta-model based framework for modeling data objects, the shape of a data object is implicitly defined in the meta-model. For example, the meta-model for AddressLite implicitly knows its shape. However, a separate corresponding query string, which also contains the data shape in the form of named table columns, is passed to the mediator to perform the data retrieval. If any field or reference is added to, removed from, or otherwise modified in the AddressLite data object, the corresponding query also requires modification. The example presented above is simple; however, for complex queries with complex data models that include many relationships between objects, the maintenance also becomes quite complex and thus is very prone to becoming “out-of-sync”. Thus, providing the data shape in two places is clearly redundant, maintenance intensive, and error prone.
Therefore, it would be advantageous to have a mechanism for defining queries that does not require the duplication of data shape information.